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(54) Routes and paths management 

(57) The invention provides a new cost-effective 
and efficient framework for network management of tel- 
ecommunications networks by monrtorirtg the network- 
level concepts of routes and paths. The invention is 
embodied in a route and path management (RPM) sys- 
tem which includes a data collector for collecting data 
from the individual network elements, a management 
server for processing the routing data collected into 
manageable route and path objects and a graphical unit 
interface (GUI) for allowing a user to manage and mon- 
itor routes and paths in the IP network. By monitoring 
routes and paths, the RPM provides network managers 
with the added capability of troLi>leshooting, perform- 
ance monitoring, service level planning and provision- 
ing packet forwarding paths between any source- 
destination endpoints in a network. 
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Description 

FIELD OF THE INVENTION 

[0001] The invention relates to network manage- s 
ment and in particular, to methods and apparatus for the 
management of routes and paths in telecomnninica- 
tions networks. 

BACKGROUND OF THE INVENTION w 

[0002] In today's large telecommunications net- 
works such as core networks used for Internet service 
providers (IMPS) or major corporate backbones, net- 
work management plays an inrportant role in maintain- is 
ing network stability, performance and efficiency. 
Network management is used to perform a variety of 
functions including the detection and correction of fault 
conditions, the identification, configuration and monitor- 
ing of use of network devices for cost allocation and per- 20 
fbrmance evaluation. 

[0003] Presently, the vast majority of networks are 
managed at the physical or device level by a centralized 
management entity comnx)nly referred to as a network 
manager server (hereinafter "network manager*^ 2s 
whereby devices in the network such as routers and 
physical layer interfaces are each individually polled by 
the network manager for status updates. However, in 
many situations, this process is not time-efficient. 
[0004] For example, in the event of a congestion 30 
point causing unusual traffic delays or a failure causing 
a traffic intenuption along a particular routing path, each 
network device located along that partk;utar path and 
involved in the transmission of the traffic delayed or 
inten-upted as a result of the congestion point or failure 35 
must be polled by the network manager to locate the 
source of the problem. Polling nmiHiple devices each 
time a problem arises along a particular routing path is 
therefore timeKX)nsuming and as a result substantially 
lengthens the time necessary to solve the problem. 40 
[0005] Because polling of nrtultiple network devices 
is time-consuming, most problems encountered in a 
network may deteriorate or improve by the time a net- 
work manager is able to track down the root of the prob- 
lem, making it more difficuK to ascertain its true nature. 45 
Moreover, in many cases, clients only report network 
problems long after their occun^ence which, by that time, 
may not be visible problems anynrx)re. This is particu- 
larly true of congestion points which are intermittent by 
their very nature and only occur in heavy traffic condi- so 
tions. 

[0006] In ascertaining the nature of a particular 
problem, it is often necessary for the network manager 
to determine which clients are affected and the manner 
in which these clients are affected. This typically ss 
requires a network-level analysis of each problem by 
considering the performance history of the particular 
routes and paths used by each client. A route is a static 



concept typically defined by a source endpoint and a 
destination endpoint in a network. By contrast, a path is 
a dynamic concept associated with a particular route. A 
path is defined as the set of network devices and their 
respective interfaces traversed by traffic travelling in a 
particular direction at any given point in time on the par- 
ticular route. 

[0007] However, current device-level management 
applications do not provide the necessary tools for effi- 
dentty monitoring routes and paths. As a result, these 
problems become virtually inpossible to solve and may 
persist indefinitely. Therefore, there is a need to provide 
network operators with the ability to monitor the per- 
formance history of routes and paths for efficient trou- 
bleshooting of problems arising in a network. 
[0008] Another drawback of the use of device-level 
management is that it does not address real-time per- 
forrrance issues at a routing path level which often arise 
in a network as a result of problems occurring at the 
de/ice level such as congestion points and link or equip- 
ment failures. Device-level management only deals with 
performance issues for which the network devices are 
individually responsible. However, this "device-level 
view" does not provide a path-level understanding of the 
overall real-time performance of all the devices drfining 
a particular path of a particular route. 
[0009] For example, in con-ecting a congestion 
problem, device-level management does not address 
whether the data transmitted on a particular source- 
destination route follows the intended patii which may 
have been specifically provisioned for it or whether it 
has been rerouted to an alternate path. 
[001 0] When traffic is rerouted due to a failure in the 
network, another real-time performance issue not 
addressed by device-level management is whether the 
alternate path chosen has tiie requisite capacity for 
accommodating the traffic delayed or interrupted or 
whether ttie traffic as redirected will maintain the same 
level of service it had prior to being redirected. As net- 
work routes are currerrtiy sokJ to network clients with a 
specific quality of service (QoS), adequate configura- 
tion and path provisioning of network routes is becom- 
ing increasingly innportant. Therefore, there is a need for 
providing a network witfi adequate real-time perform- 
ance monitoring and path provisioning capability for 
maintaining performance in a network and meeting ever 
increasing QoS demands. 

[001 1 ] The need to deal with device-level protslems 
in a more time-efficient nr^nner and address real-time 
performance issues arising as a result of the occunrence 
of device-le^el problems has triggered the emergerKe 
of what is now known in network management as trace 
routing. Trace routing applications allow some form of 
network-level management of paths and routes by rely- 
ing on test messages to perform patti discovery of spec- 
ified routes. In particular, current trace routing 
implementations determine the path likely to be followed 
by traffic for a particular source-destination route by 
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sending one or wore test packets from the source node 
to the destination node and summarizing the results. 
However, this method has a number of disadvantages. 
First the trace routing of any given source-destination 
route can only be performed from the source node. 5 
Another disadvantage is that most network devices are 
not properly instrumented to do tNs function and do not 
treat the test packets with the same priority than normal 
traffic. Therefore, the results obtained with this method 
are not truly representative of how the network devices 10 
handle their respective traffic in real-time. As a result 
there is a need for an innproved network management 
system for managing and nxjnitoring paths and routes 
in a network and also for nwnitoring the behaviour of 
network devices in real-time. 15 

SUMMARY OF THE INVENTION . 

[0012] rt is an object of the invention to obviate or 
mitigate one or moTQ of the above identified disadvan- zo 
tages and shortcomings of current network n^anage- 
ment applications. 

[0013] The invention provides a cost-effective and 
efficient new route and path management (RPM) frame- 
work for network management of telecommunications 25 
networks by monitoring the network-level concepts of 
routes and paths. By monitoring paths and routes in a 
networK the RPM system provides network managers 
with the added capability of troubleshooting, perform- 
ance monitoring. servk;e level planning and prevision- 30 
tng paths between any source-destination erxlpoints 
(routes) in a network. In a preferred embodiment, the 
RPM system is incorporated in an Internet protocol (IP) 
network and is designed to be operable in a sinrple net- 
work management protocol (SNMP) environment. The 35 
RPM system is comprised of a data collector for collect- 
ing routing data from the individual network devices, a 
management server for processing the routing data col- 
lected into manageable route and path objects for trac- 
ing and performance monitoring, a database for storing 40 
the results and a graphical unit interface (GUI) for allow- 
ing a user to trace routes and paths in the IP network 
and monitor routing performance. 
[0014] By oonrtparison device-level manage- 
ment applications, the present invention advanta- 45 
geously allows the real-time determination of 
permissible patiis having the requisite capability for the 
transmission of data on a given set of routes and routing 
protocols. 

[001 5] Yet another advantage of the present inven- so 
tion compared to device-level management techniques 
is tfiat It provides means for storing and providing, on 
demand, route history and patii-level multi-metric per- 
formance history for future provisioning and trouble- 
shooting of the routes and patiis monitored. ss 
[0016] Similarly to current device-level manage- 
ment applications, the invention allows real-time moni- 
toring and reporting of device-level performance. Yet 
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still another advantage of the present invention over 
device-level maragement is that it also provides path- 
level real-time and historical performance of routes and 
paths monitored. 

[0017] Yet still anotiier advantage of the present 
invention over device-level management techniques is 
tiiat it provides means for raising or clearing quality of 
service (QoS) alarms against routes and paths moni- 
tored. 

[0018] In another preferred embodiment the RPM 
system as described above also has a management 
information base (MIB) in which the route and path 
ot^ects managed by the n^nagement server are made 
available to other network entities and applications via 
SNMR 

[0019] Yet still another advantage of the present 
invention is tiiat by using an MIB for SNMP storage of 
the route and path objects managed, the tracing and 
routing performance results generated by the manage- 
ment server may be renrotely accessed by any SNMP 
entity. 

[0020] Other aspects and features of tiie present 
invention will become apparent to those ordinarily 
skilled in the art upon review of the following description 
of specific embodiments of the invention in conjunction 
with the acconrpanying figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0021] Preferred embodiments of the invention will 
now be described with reference to the attached draw- 
ings in which: 

FIG. 1 is a block diagram of an Internet protocol 

network hereinafter the ("IP network"); 

FIG. 2 is a block diagram of a first embodimerrt of 

the route arxJ path nranagement (RPM) system of 

node 1 of the IP network of Figure 1 ; 

FIG. 3 is a diagram of the graphical user interface of 

tiie RPM system of Rgure 2; 

FIG. 4 is a more detailed block diagram of the RPM 

system of Figure 2; 

FIG. 5 is a block diagram of the path trace & nronrtor 
logic unit as inrplemented in the RPM system of 
Rgure 4; 

FIG. 6 is a flowchart of the nr^ain steps required for 
discovering the paths of a specified route histori- 
cally and in real-time; 

FIG. 7 is a flowchart of the main steps executed by 
tiie path trace algorithm used for discovering the 
paths of a specified route historically and in real- 
time; 

FIG. 8 is a block diagram of tiie performance moni- 
tor logic unit as implemented in the management 
server of the RPM system of Figure 4 for providing 
real-time performance monitoring of a specified 
route: 

FIG. 9 is a block diagram of the performance moni- 
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tor logic unit as implemented in the management 
server of the RPM system of Rgure 4 providing his- 
torical performance monitoring of a specified route; 
FIG. 10 is a block diagram of the historical path & 
performance broker as Implemented in the man- 5 
agement server of the RPM system of Rgure 4; and 
FIG. 11 is a block diagram of a second embodiment 
of the RPM system of Figure 2. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0022] This invention provides a cost-efficient and 
effective framework for network management of tele- 
communications networks by monitoring the network- 
level concepts of routes and paths. According to a pre- 
ferred ennbodlment the present invention is en^xxJied 
as a route and path nrtanagem&it (RPM) system 
designed to be operable in a simple network manage- 
ment protocol (SNMP) environment. 
[0023] The RPM system can be incorporated in any 
network topology or configuration. For simplicity how- 
ever, the invention will now be desaibed only in relation 
to an Intemet protocol network (hereinafter the "IP net- 
work"). This IP network is shovim in Rgure 1 as 10. 
[0024] The IP network 10 illustrated therein is com- 
posed of a plurality of nodes commonly indicated by 1 1 
and individually numbered 1 through 8. Each of these 
network nodes 11 Is linked to others of the network 
nodes 1 1 by one or more communication links respec- 
tively labelled A through L (A-L). Each such communi- 
cation link A-L may be either a pennanent connection or 
a selectively enabled (dial-up) connection. Any or all of 
the network nodes 1 1 may be connected to one or more 
edge nodes commonly indicated by 12 for communica- 
tion with other nodes or networks (not shown) located 
outside of the IP network 10. For exanple. in the IP net- 
work of Figure 1. nodes 2, 7 and 8 are connected to a 
respective edge node 12. These edge nodes are indi- 
vidually numbered 13. 14. 15. 
[0025] The network nodes 11 each comprises a 
data processing system (not shown) wNch provides 
data communications services to ail connected nodes, 
network nodes 1 1 and edge nodes 12, as well as pro- 
viding decision units (not shown) within the node 1 1 . At 
each network node 11, the decision units present 
therein serve to selectively route incoming data packets 
on one or more of the outgoing communication links A- 
L for transmission to other nodes 1 1 or edge nodes 12. 
Such routing decisions are made in response to infor- so 
mation in the header of each data packet received. 
[0026] In the IP network 10, the overall manage- 
ment of the IP network 10 of Figure 1 is performed by a 
centralized network management system which can be 
found In or attached to any one of the network nodes 1 1 ss 
shown in Figure 1 . For clarity, the network management 
system will now be described below as being part of 
node 1 in reference to Rgures 2 through 9 and as such. 



node 1 is hereinafter referred to as the onetwork man- 
agerci However, it is to be understood that the network 
nnanagement system could alternatively be inrple- 
mented in any other node 1 1 of the IP network 10 or in 
the further alternative, implemented in multiple nodes 
11 of the IP network 10. 

[0027] In the IP network 10 of Figure 1 , the network 
manager 1 is responsible for executing management 
applications such as the integrated network manage- 
ment (INM) application for monitoring and controlling 
network elements or NEs. Network elements are 
devices such as the edge nodes 12. network nodes 1 1 
and their associated routers and interfaces. In order to 
be managed by the network manager 1 , these network 
elements are each assigned to a management agent 
respons^e for performing the network management 
functions requested by the network manager 1 . 
[0028] As is well known, the agents are responsible 
for accessing information atxxrt the network elements 
assigned to them and make it available to the network 
manager 1. For example, an agent might report the 
number of bytes and packets in and out of a particular 
network element, or the number of messages sent and 
received by that network element during a given time 
period. These variables are referred to as managed 
objects and are maintained in a database referred to as 
a management information base (MIB) unique to each 
network element. Therefore, when the network man- 
ager 1 requests information relating to a particular ele- 
ment of the IP network 10. that information is obtained 
from the associated MIB via the agent assigned to the 
particular network element. In the following desaiption 
of the IP network 10. the M IBs and associated agents 
are not always referenced specifically However, it is to 
be ur)derstood that by referring to the network elements, 
reference to the associated MIBs and agents is implied. 
[0029] As noted above, the RPM system 20 of the 
IP network 10 is implemented to be operable in an 
SNMP environment Although not essential to this 
invention, the SNMP intplementation is highly desirable 
for promoting interoperability and facilitate the 
exchange of management infomnation between the net- 
work manager 1 and the agents of the respective net- 
work elements. 

[0030] Referring now to Figure 2, the network man- 
ager 1 is provided with the RPM system 20 which pro- 
vides the functionality required for troubleshooting, 
performance monitoring, service level planning and pro- 
visioning of paths and/or network elements for any 
source-destination route in the IP network 10. The RPM 
system 20 is comprised of a management server 22 for 
providing the RPM functionality described above which 
is connected to an external database 25. The RPM sys- 
tem 20 also has a standard SNMP data collector (here- 
inafter simply refen^ed to as "data collector") 21 
connected to the management server 22 which is 
responsible for handling SNMP communications 
between the management server 22 and the network 
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elements of the IP network 10, and a graphical user 
intertace (GUI) 23 connected to the management server 
22 for allowing a user to reacfty access and make use of 
the RPM functionarrty for managing the IP network 10 at 
a network level. 5 
[00311 According to a prefened embodiment, the 
RPM system 20 is incorporated in the network manager 
1 as an add-on to the des^ce-tevet network management 
functionality provided by a well-known standard network 
management application referred to as integrated net- io 
work management (INM) 26. As such, for the RPM sys- 
tem 20 description provided below, it is to be assumed 
that the RPM system 20 is designed to be launched 
from INM 26. It is to be understood that the RPM system 
could alternatively be designed as an add-on to other is 
network management applications or in the further 
alternative, as a stand-alone network management 
application. The specific steps required to implement 
the RPM system 20 as a stand-alone network manage- 
ment application or the steps to integrate the RPM sys- 20 
tem 20 into INM 26 or any other network management 
application would be obvious to a person skilled in the 
art and. as such, is not described here in any detail. 
[0032] Refening now to Rgure 3. there is illustrated 
the GUI 23 used according to the preferred embodiment zs 
of this invention to enable a GUI user to specify and 
monitor routes, paths and associated network ele- 
ments. When operational, the GUI 23 produces a main 
computer window which is subdivided into 5 sectior^. 
More specifically, sections 30, 31 , 32 of the main com- 30 
puter window are located on the left hand side of the 
main computer v^ndow to form a left handed pane white 
sections 4 and 5 are located on the right hand side of 
the main window forming a right handed pane. 
[0033] Sectk>ns 30. 31. 32 of the left handed pane 35 
each contains a respective table. In particular, section 
30 contains a table which can be used by the GUI user 
to specify the routes to be nranitored (hereinafter the 
"route table"). In order to specify a particular route, the 
route table of section 30 contains 3 column fiekJs in 40 
which a GUI user can enter the parameters assodated 
with that route. More specifically, the first column field 
corresponds to the route name, the second column field 
corresponds to the route source IP and the third column 
field corresponds to the route destination IP. 45 
[0034] Section 31 contains a table (hereinafter the 
"path table") for displaying the paths associated with a 
particular route when the route is selected in the route 
table 30 by the GUI user. The path table 31 contains a 
path colour column and a path name column for identi- so 
tying each path of the selected route with a particular 
colour and name. 

[0035] Section 32 contains a table (hereinafter the 
"path instance table") for displaying the paths instances 
associated with a particular path when the path is ss 
selected in the path table 31 by the GUI user. Each path 
instance provides the parameters of a particular path for 
a given time. The path instance tat^e 32 contains 5 col- 



umn fields for the following path attributes: (1) time 
stannp. (2) path direction, (3) percentage of utilization. 
(4) enrors and discards and (5) latency. 
[0036] Sections 33 and 34 of the right handed pane 
each contains a respective notepad for graphically dis- 
playing RPM results corresponding to the routes and 
paths specified in tables 30. 31 and 32. 
[0037] In particular, section 33 contains a notepad 
for graphically c£splaying the nodes, interfaces and links 
of the routes and paths selected in tables 30. 31 and 32. 
The notepad of section 33 has 3 display nrKxles, namely 
a linear graphics mode, a route network graphics mode 
and a network graphics mode. These modes are selec- 
tively enabled by way of a respective pull-down menu 
located in a top portion of section 33. 
[0038] In the linear graphics mode, the selected 
route and its associated paths, nodes and interfaces are 
shown in the notepad of section 33 on a straight line 
wnthout regard to the actual layout of the IP network 10. 
Based on the parameters specified in tables 30. 31. 32, 
three display scenarios are possible. First, when a route 
is selected in the route table 30, only the source and 
destination nodes are shown in the notepad of section 
33. Secondly, when a path of a particular route specified 
in the route table 30 is selected in the path table 31 , all 
the nodes and interfaces associated with the path 
selected are shown on a straight tine in addition to the 
source and destination nodes. Thirdly, when a path 
instance of a particular path selected in the path table 
31 is selected in the path instance tat>te 32. all the 
nodes and interfaces of the fonward path are shown on 
a top straight line and alt the nodes and interfaces of the 
backward path are shown on a bottom straight line 
below the forward path. 

[0039] In the route networi^ graphics nrxxJe, the 
selected route and its associated paths, nodes and 
interfaces are shown in the notepad of section 33 where 
the nodes and interfaces are displayed as positioned in 
the IP network 10. In other words, the location of the 
nodes and interfaces as displayed in the notepad of 
section 33 is representative of their actual location in the 
IP network 10. 

[0040] In the network graphics mode, the paths, 
nodes and interfaces of all the routes specified in the 
route table 30 are displayed in the notepad of section 33 
in the same manner the selected route and its associ- 
ated paths, nodes and interfaces are shown in the route 
network graphics nxxje i.e. the nodes and interfaces are 
displayed as positioned in the IP network 10. 
[0041] Section 34 of the right handed pane also 
contains a notepad for graphically displaying real-time 
and history perfbrnoance charts for any one of the 
routes specified in the route table 30 or any one of its 
associated paths, nodes or interfaces. 
[0042] Accading to the preferred embodiment of 
the invention, the GUI 23 is designed to allow the GUI 
user to specify the rate at which the selected route and 
paths are to be monitored. The monitoring rate is 
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defined by the rate at which the network elements are 
polled by the n^nagement server 22 (see below) which 
corresponds to the rate at which the Infornnation in the 
GUI 23 is to be updated. This rate is hereinafter referred 
to as the polling rate and for the GUI 23 of the present 
invention, this rate is set to 10 minutes. 
[00^] In operation, the tables 30. 31/32 and the 
section 33 and 34 notepads are empty. In order to spec- 
ify a particular route, the GUI user enters the parame- 
ters associated with that route in the route table 30 and 
in particular, the route name, the route source IP arxi 
the route destination IP As the GUI user wishes to mon- 
itor more routes, these routes can also be specified in 
the route table 30 by entering their respective route 
parameters i.a the route name, the route source IP and 
the route destination IP 

[0044] Once the desired routes have been specified 
into the route table 30, each particular route contained 
therein may then be selectively monitored at the rate 
specified by the monitoring rate (see above). In order to 
monitor a particular route, the route must first be 
selected (highlighted) in the route table 30. As this 
occurs, all the paths associated with that particular 
route will appear in the path table 31. When a path is 
selected annong the paths contained in the path table 
31 » all of the instances of the selected path will be dis- 
played in the path instance table 32. As a resuft. each 
path instance of the selected path will be displayed 
showing the parameters of the selected path for specific 
times. The notepads in sections 33 and 34 can be used 
thereafter for monitoring the performance and path 
changes of the path instances listed in the path instance 
table 32. 

[0045] Refening now to Figure 4, there is illustrated 
a more detailed block diagram of the RPM system 20 of 
Figure 2. Briefly stated, the RPM system 20 provides 
real-time and historical tracing of routes and paths 
specified by a user through the GUI 23 as well as real- 
time and historical performance monitoring of the routes 
and patlis specified. This route tracing and performance 
monitoring functionality is embodied in the manage- 
ment server 22 to provide the network manager 1 with 
the added capability of troubleshooting, performance 
nrK)nitoring, service level planning and provisioning 
paths between any source^iestination endpoints 
(routes) in the IP network 10 of Rgure 1 . 
[0046] In order to canry-out the above-mentioned 
functionality, the management server 22 is conprised of 
a path trace & nrranitoring logic (T&ML) unit 41 for the 
real-time and historical tracing of a specified route, a 
performance monitaing logic (ML) unit 42 for nwnitor- 
ing the performance of the paths associated with a 
specified route and a historical path & performance bro- 
ker 43 for analysing past trace and performance results. 
The management also has a collector interface (com- 
munication layer) 40, a database (OB) manager 46. a 
request dispatcher 45, a server remote method invoca- 
tion (RMI) interface 47 and a notification channel 44 all 



interconnected with the path T&ML unit 41, the path & 
performance broker 43 and the perfornr^ce ML unit 42 
in the following manner. The collector interlace 40 is 
^ernalty connected to the data collector 21 through an 

5 RMI interface 50 and internally connected to both the 
path T&ML unit 41 and the performance ML unit 42. The 
path T&ML unit 41 is connected to the performance ML 
unit 42 and also to the notification channel 44. The noti- 
fication channel 44 is externally connected to the GUI 

10 23 via the RMI 48 intennal to the GUI 23. The perform- 
ance ML unit 42 is also connected to the notification , 
channel 44 and to the DB manager 46 providing con- 
nectivity with the datatase 25 external to the nr^age- 
ment server 22. The management server 22 also has 

75 the request dispatcher 45 connected to receive 
requests from the GUI 23 via the server RMI 47 internal 
to the management server 22. The request dispatcher 
45 is connected to the DB manager 46, the path T&ML 
unit 41 . the historical path & perforniance broker 43 and 

20 the performance ML unit 42. 

[0047] The following section will now describe in 
detail and in reference to Figures 5 through 10 the oper- 
ation of the management server 22 in terms of the archi- 
tecture and functionality of each of its path T&ML unit 

25 41, historical path & performance broker 43 and per- 
formance ML unit 42. 

[0048] Referring firstly to Rgure 5, the RPM system 
20 is shown with a more detailed block diagram of the 
path T&ML unit 41 as implemented in the management 

30 server 22 for providing real-time and historical tracing of 
a specified route. In particular, the path T&ML unit 41 is 
comprised of a path trace handler 55. a source and des- 
tination register 56. a path objects assemtrfer 57. a "get 
next hop" logic block 58. a queuing manager 60. and a 

35 path change nronitor logic 59 all interconnected within 
the management server 22 as follows. The path trace 
handler 55 is connected to the request dispatcher 45 
and to the DB manager 46. The source and destination 
register 56 is connected to the queuing manager 60 aruJ 

^ to the path objects assenti&ler 57. The path objects 
assembler 57 is, in turn, connected to the get next hop 
logic 58 and the path change monitor logic 59. The path 
change monitor logic 59 is coupled to the DB manager 
46, the notification channel 44. the performance ML unit 

45 42 and the get next hop logic 58. The get next hop logic 
58 is externally connected to the data collector 21 via 
the collector interface 40. 

[0049] The real-time tracing operation of the man- 
agement server 22 is triggered when the user requests, 

50 through the GUI 23. that a particular route be traced in 
real-time. The request dispatcher 45 receives the user's 
request and places it into the path trace handler 55. The 
path trace fnandter 55 operates to separate the route 
tracing request into its constituent source and destina- 

55 tion endpoint components and subsequently forwards 
them to the DB n^nager 46. Upon receipt, the DB man- 
ager 46 requests from the database 25 all the associ- 
ated source and destination objects (interfaces) for the 
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source and destination endpoint components of the 
specified route. 

[0050] Once captured from the database 25. the DB 
manager 46 places the source and destination objects 
into the queuing manager 60 which is responsible for 
queuing and processing route tracing requests accord- 
ing to a high priority, a real-time priority, a historical high 
priority or a historical low priority. For a real-time trace 
routing request, the DB manager 46 places the source 
and destination objects of the route specified by the 
user into the queuing manager's real-time queue for 
processing. When the queuing manager samples the 
real-time queue, it then draws the source and destina- 
tion objects associated with the specified route and 
sends them into the source and destination register 56 
for further processing. 

[0051] For each of the source endjpoint and inter- 
mediate points located between the source endpoint 
and the destination endpoint the path objects assem- 
bler 57 asks the get next hop logic 58 (further details 
below) to find the next hop to the destination endpoint 
until it actually hits the destination endpoint. This results 
in the discovery (assembly) of all the paths used in real- 
time by traffic being transmitted on the specified route 
from the source endpoint to the destination endpoint. 
each path being defined as a manageable object con- 
taining a respective set of network dey/ices and associ- 
ated interfaces located between the source endpoint 
and the destination endpoint of the specified route. 
These paths are hereinafter refenred to as lonward 
paths**. This path discovery process is repeated for 
assembling the paths used for transmitting traffic from 
the destination e^point to the source endpoint (herein- 
after referred to as l>ackward paths'^. 
[0052] For each forward arxl backward path assem- 
bled, the path objects assembler 57 places the corre- 
sponding constituent network devices and associated 
interfaces into a respective path list for notification back 
to the user which can then access this information via 
the GUI 23 (see above). The path objects assembler 57 
also operates to temporarily store the results of the 
paths discovered into the database 25 through the DB 
manager 46 in order to save the results of the real-time 
tracing operation for real-time performance analysis. 
The path objects assembler 57 then informs the per- 
formance ML unit 42 to begin sending real-time per- 
formance data back to the user through the GUI 23 
(further details below). 

[0053] As routing in a network is dynanrtic. the paths 
discovered for the route specified are monitored period- 
ically by the path change monitor logic 59 for path 
changes. In particular, the paths are rediscovered and 
checked against the existing paths at the polling rate 
specified by the user in the GUI 23. If the rediscovered 
paths differ from the existing paths in any way (by a sin- 
gle network device a a single interface), this causes the 
paths to be updated or new paths to be associated with 
the specified routa If there is any path changes, an 



alarm is generated by the path change monitor logic 59 
for the GUI user through the notification channel 23. 
[0054] There may be situations where path 
changes occur between polling events which are worthy 

5 of notification to the GUI user. To address these situa- 
tions, the RPM system 20 is designed with the ability to 
handle traps generated by network elements 24 and 
notify tiie GUI user of significant events. 
[0055] Traps generated by network elements 24 are 

10 received into the management server 22 tiirough a trap 
gatherer 61 which is preferably implemented in the data 
collector 21. The trap gatherer 61 forwards each trap 
received to a trap handler 62 which is internal to the 
management server 22. Upon receiving a trap from a 

15 particular network element 24. the trap handler 62 
requests that all paths associated with that particular 
network element 24 be placed into the high priority 
queue for processing so that the GUI user can be noti- 
fied of the changes. 

20 [0056] In order to trigger the historical tiBcing oper- 
ation of the management server 22. the user has to 
request, through the GUI 23. tiiat a particular route be 
monitored so that the results of tiie tracing operation be 
saved pemnanentiy in the database 25 for sut)sequent 

25 historical analysis. Similarly to the real-time tradng 
operation of the management server 22, the user's his- 
torical route trace request is received in the request dis- 
patcher 45 which places it into tiie path trace handler 
55. The path trace handler 55 operates to separate the 

30 historical trace route request into its constituent source 
and destination endpoint components and subse- 
quently forwards thern to the DB manager 46. Similarly 
to the manner in which a real-time route fe-ace request is 
processed, the DB manager 46 then requests and cap- 

35 tares from tiie database all the associated source and 
destination objects (interfaces) for the source and desti- 
nation endpoint components of the specified route and 
registers each object pair as a historical monitored 
route into a route list maintained in the database 25 for 

40 all historical nrwnitored routes. 

[0057] In order to service the user's historical route 
trace request, tiie queuing manager 60 periodically 
requests tiiat the DB manager 46 provides it witti a list 
of all source and destination object pairs stored in the 

45 route list of the database 25 and places them in its low 
priority queue. The queuing manager 60 will tiien 
sequentially send, in accordance with its ddined priority 
levels, the tow priority object pairs queued to tiie source 
and destination register 56 for processing and subse- 

50 quent fonwarding to tiie path assembler 57. The path 
objects asserrtoler 57 operates in the same manner it 
operates when assembling (discovering) paths in 
response to a real-time route trace request. Accordingly, 
in tills case, the path objects assembler 57 operates to 

55 assemble all of tiie fonn^rd and backward paths associ- 
ated with the route specified, requests that tiie patii 
change monitor logic 59 monitor tiie paths discovered at 
the polling rate and notify the user via the notification 
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Channel 44 ot any path changes observed as a result of 
a new poll or a trap received from the IP network 10. 
[0058] However, in contrast to real-time operations, 
the path objects assembler 57 operates to permanently 
store the results of the paths discovered into the data- 
base 25 through the DB manager 46 In order to save the 
results of the historical tracing operation. By sending an 
appropriate request to the management server 22. the 
GUI user can then obtain the historical information 
stored for subsequent historical performance analysis. 
[0059] To further explain the real-time and historical 
tracing operation of the management server 22, a flow- 
chart is shown in Figure 6 illustrating the nrtain steps 
performed by the management server 22 in servicing a 
real-time or historical route tracing request for discover- 
ing the paths of the route specified. From this flowchart 
it can be observed that the tracing operation of a partic- 
ular route is triggered by the user which specifies the 
source and destination endpoints of the route. It can 
also be observed that if historical monitoring is per- 
formed, the source and destination endpoints of the 
specified route are permanently saved in the database 
25 (Rgure 5) for subsequent historical analysis. It can 
still be further observed that for each of the source end- 
point and intermediate points located between the 
source endpoint and the destination endpoint which are 
traversed by traffic travelling from the source endpoint 
and the destination endpoint all the associated forward 
paths are discovered. It can still be further observed that 
this path discovery process is repeated for the back- 
ward paths associated with the particular route speci- 
fied. 

[0060] As noted above in reference to Figure 5. the 
fonvard paths and backward paths are assembled by 
running a path trace algorithm. This particular algorithm 
is run by the get next hop logic 58 of Figure 5 which, for 
the source endpoint or any of the intermediate points 
located between the source endpoint and the destina- 
tion endpoint, operates to find the next intermediate 
point (hop) to the destination endpoint until it actually 
hits the destination endpoint. This involves sequencing 
through each intermediate point located between the 
source endpoint and the destination endpoint of the 
specified route and gathering routing and interface 
information specific to each intermediate point The 
information gattiered is then processed by the path 
objects assembler 57 (see Rgure 5) fa assembling the 
paths associated to the specified route. 
[0061] To further describe this, reference is now 
made to Figure 7 which contains a flowchart of the 
sequencing operation of the p>ath trace algorithm 
referred to at>ove. From this flowchart, it can be 
observed that based on the particular source endpoint 
specified by the GUI user, the path trace algorithm ini- 
tially runs a device discovery routine for gatiiering iden- 
tification information about that particular source 
endpoint Next an interface discovery routine is run for 
determining the input interface associated with tiie par- 



ticular source point specified. Next, tiie path trace algo- 
rrthm runs a routing information discovery routine for 
obtaining information about the manner in which the 
source endpoint routes traffic interxjed for the destina- 

5 tion endpoint. Next, tiie path trace algorithm runs a get 
next hop discovery routine to find the next hop in the 
path to the destination endpoint which is followed by a 
leave interface discovery routine run to determine the 
particular output interface associated with the source 

10 endpoint. Next, tiie next hop is conrpared to tiie destina- 
tion endpoint supplied by the GUI user and if the next 
hop is the destination endpoint. a path to tiie destination 
endpoint is found and reported to the path objects 
assembler 57. If the next hop is not tiie destination end- 

15 point, then the next hop is fed back into the path trace 
algorithm which runs again for determining the next hop 
in the patii to the destination endpoint. This process is 
repeated until the next hop becomes tiie destination 
endpoint at which time, as noted above, tiie path found 

20 is reported to the path objects assemt^er 57 (Rgure 5). 
[0062] Referring now to Rgure 8. there is illustrated 
a more detailed block diagram of tiie performance ML 
unit 42 of Rgure 4 as implemented in the management 
server 22 for providing real-time performance monitor- 

25 ing of a specified route. 

[0063] The performance ML unit 42 is comprised of 
a monitoring queue 65 externally connected to both tiie 
request dispatcher 45 and tiie DB manager 46 and 
internally connected to a route queue 66. a path queue 

30 67 and an object queue 68. These queues 66, 67, 68 
are respectively used for holding identification data 
related to routes, patiis and associated objects (network 
devices, interfaces, etc.) which is periodically updated 
from the database 25 each time a real-time perform- 
as ance monitoring request comes in from tiie request dis- 
patcher 45 (furtiier details below). The route, path and 
object queues 66, 67. 68 are respectively connected to 
a corresponding route, path and object performance 
logic unit 70, 71 69. The object performance logic unit 

40 69 is externally connected to tiie data collector 21 
through the communication layer 40 and also internally 
connected in series to the path and the route perform- 
ance logic units 70. 71. Rnally, each of the route, path 
and object performance logic units 71 . 70. 69 is exter- 

45 nally connected to the notification channel 44. 

[0064] According to tiie preferred embodiment of 
the present invention, the real-time performance moni- 
toring operation of tiie management server 22 is b'ig- 
gered as tiie user requests, through the GUI 23. tiiat tiie 

50 performance of a particular route be monitored in real- 
time. This usually occurs after the specified route has 
been traced in real-time when the patii objects assem- 
bler 57 of tiie path T&ML unit 41 (see Rgure 5) requests 
the performance ML unit 42 to begin sending real-time 

55 performance data back to the user through the GUI 23. 
[0065] When such a request is initiated, it is 
received in the monitoring queue 65 which, as a result, 
proceeds to update the information contained in each of 
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the route, path and objects queues 66. 67. 68 with new 
identification data which was previously temporarily 
stored in the database 25 by the path objects assennbler 
57 (Rgure 5) in executing the associated request for 
real-time tracing of the route specified. This new identi- 5 
fication data is added to the existing (old) identification 
data contained the corresponding queue 66. 67. 68. 
The object performance logic 69 begins polling each 
network object listed in the object queue 68 (new and 
old) through the data collector 21 to obtain performance 10 
data for each of the objects listed. The object perform- 
ance logic 69 then fooA^ards the polled responses 
obtained to the notification channel for notification to the 
GUI 23. 

[0066] The polled responses are also sent to the i5 
path performance logic 70 together with the polled 
objects where the objects polled are compared to 
threshold data contained in the path queue 67 and per- 
formance for each of the paths listed therein is calcu- 
lated. The path performance logic 70 will then notify the 20 
route performance logic 71 that it has completed the 
path performance analysis for the particular objects 
polled and forward its performance results to the notifi- 
cation channel 44 for transmission to the GUI 23. The 
path performance logic 70 also proceeds to fonvard its 25 
performance results together with the paths for which 
performance was calculated to the route performance 
logic 71 which compares the paths obtained from the 
path performance logic 70 with the old identification 
data corrtained in the route queue 66 and calculates an 30 
overall route performance metric which is then transmit- 
ted to the GUI 23 through the notification channel 44. 
The real-time monitoring operation of the management 
sender 22 just described above is repeated at the polling 
rate specified by the user through the GUI 23. 35 
[0067] Referring now to Rgure 9. there is illustrated 
a more detailed block diagram of the performance f^L 
unit 42 of Rgure 4 as inrplemented in the management 
server 22 for providing historical performance monitor- 
ing of a specified route. The route queue 66, a path 40 
queue 67 and object queue 68 described above are 
also used by the performance ML unit 42 fa historically 
monitoring the performance of a specified route. It will 
be recalled that the queues 66, 67, 67 are respectively 
used for holding identification data related to routes, 45 
paths and associated objects (network devices, inter- 
faces, etc.). As will be described below, this identifica- 
tion data is periodically updated from the database 25. 
The route, path and object queues 66. 67. 68 are 
respectively connected to a corresponding route, path so 
and object performance monitor logic 74, 73, 72. The 
object performance monitor logic unit 72 is externally 
connected to the data collector 21 through the commu- 
nication layer 40 and also internally connected in series 
to the path and the route performance nnonitor logics 73, 55 
74. Finally, each of the route, path and object perform- 
ance nnonitor logics 74, 73, 72 is externally connected to 
the notification channel 44. 



[0068] The historical performance monitoring oper- 
ation of the management server 22 is initially triggered 
by a request from the user, through the GUI 23. that the 
performance of a particular route be historically moni- 
tored. Upon fc>eing requested to initiate historical per- 
formance monitoring of a specified route, the historical 
performance ML unit 42 polls the associated objects 
through the data collector 21. computes the perform- 
ance of each of the objects polled and with these 
results, computes the perfornnance of each path associ- 
ated with the specified route and again with these 
results, computes the performance of the specified 
route itself. All of these performance results are perma- 
nently saved in the database 25 for subsequent histori- 
cal analysis. 

[0069] More specifically, when a historical perform- 
ance monitoring request is initiated, it is received in the 
rrkonitoring queue 65 which, as a result, proceeds to 
update the information contained in each of the route, 
path and objects queues 66. 67, 68 with new identifica- 
tion data which was previously permanently stored in 
the database 25 by the path objects assent)ler 57 in 
executing the associated request for historical tracing of 
the route specified. This new identification data is added 
to the existing (oW) identification data contained the cor- 
responding queue 66, 67, 68. 
[0070] The object performance nnonitor logic 72 
begins polling each network object listed in the object 
queue 68 (new and old) through the data collector 21 to 
obtain performance data for each of the objects listed. 
The object performance monitor logic 72 then fbnwards 
the polled responses obtained from the data collector 
21 to the notification channel for notification to the GUI 
23. The polled responses are also sent to the path per- 
formance monitor logic 73 together with the polled 
objects where the objects polled are compared to the 
old identification data contained in the path queue 67 
and performance for each of the active paths listed 
therein is calculated. The path performance nnonitor 
logic 73 will then notify the route performance nnonitor 
logic 74 that it has completed the path performance 
analysis for the particular objects polled and fonward its 
performance results to the notification channel 44 for 
transmission to the GUI 23. 

[0071] The path performance nnonitor logic 73 also 
proceeds to fonnrard its performance results together 
with the paths for which performance was calculated to 
the route performance monitor logic 74 which compares 
the paths obtained from the path performance logic 73 
with the old identification data contained in the route 
queue 66 and calculates an overall route performance 
metric which is then transmitted to the GUI 23 through 
the notification channel 44. 

[0072] The performance of the specified route and 
each of the associated paths and objects is also meas- 
ured against appropriate performance thresholds 
located in the threshold crossing logic 75. If any per- 
formance threshold is breached for any of the objects, 



9 



17 



EP 1 043 871 A2 



18 



paths or the specified route itself, the user is notified 
through the rKjtification channel 44. Once the threshold 
calculations have been completed, the historical per- 
formance monitoring process described above is car- 
ried out again to obtain new performance values which s 
are also permanently stored in the database and 
checked against appropriate performance thresholds. 
The historical ()erformance monitoring process is 
repeated until terminated by the user via the GUI 23. 
[0073] Referring now to Rgure 10» the historical 
path & perfomnance broker 43 as irrplemented in the 
management server 22 allows the user to retrieve the 
historical route and performance data respectively col- 
lected and permanentiy stored in the database 25 as a 
result of carryir^ out historical route trace requests and 
historical performance monitoring requests. 
[0074] The historical path & performance broker 43 
is comprised of a path trace handler 80. a path gatherer 
81, an information register 83, an event & performance 
gatherer 82, a solution provider 84 and a calculation 
server 85 all interconnected within tiie management 
server 10 as follows. The path trace handler 80 is exter- 
nally connected to the request dispatcher 45 and the DB 
manager 46. Also externally connected to the DB man- 
ager 46 Is tiie patii gatherer 81 and the event & perform- 
ance gatherer 82. The path gattierer 81 is also 
connected to the information register 83, the event & 
performance gatiierer 82 and the solution provider 84 
while the event & performance gatherer 82 is also con- 
nected to tiie calculation server 85. Lastiy, in addition to 
being connected to ttie path gatiierer 81, the informa- 
tion register 83 is also externally connected to the queu- 
ing manager 60. 

[0075] As noted above, the historical path & per- 
formance broker 43 allows the user to ret'ieve the his- 
torical performance or route data associated with a 
particular route which has been collected and perma- 
nentiy stored in the database following the execution of 
previous historical route trace requests or historical per- 
formance monitoring requests. In order to do this, the 
user initiates a request tiirough tiie GUI 23 specifying a 
particular route and tiie desired time period for which 
the historical performance data or route data is to be 
reti-ieved. The user's request is received in the request 
dispatcher 45 which places it into the patii trace handler 
80. The path trace handler 80 operates to extract from 
the historical reti-ieval request tiie specified time period 
and tiie source and destination endpoint components 
defining the route for which historical data is to be 
retrieved. The path trace handler 80 subsequerrtly for- 
wards them to the DB manager 46 which then requests 
and captures from the database 25 all the paths assod- 
ated with the specified source and destination endpoint 
components of the specified route for the desired time 
period. 

[0076] Once captured from the database 25. tiie DB 
manager 46 places the paths into the queuing manager 
60 for processing. The queuing manager 60 wiil then 



sequentially send, in accordar^e with its defined priority 
levels, tiie patiis queued to tiie information register 83 
for further processing. The patti gatiierer 81 ttien reads 
tiie paths from the information register 83 and. for each 
path read, requests the event & performance gatherer 
82 to reti'ieve all associated routing events and perform- 
ance information from the database 25. The event & 
performance gatherer 82 together with the solution pro- 
vider 84 operate to process the data collected from the 
database 25 into a format suited for use by the GUI 23 
through the notification channel 44. 
[0077] Referring now to Rgure 1 1 . there is shown a 
second embodiment of the RPM system 20 where a 
MIB 90 is also used to temporarily store tiie routing and 
performance information gatiiered by the management 
server 22. In order to store this information, the MIB 90 
also has defined the network-level concepts of routes 
and paths as manageable objects. These routes and 
patiis objects can then be accessed by SNMP agents of 
ottier network elements 24 of the IP network 10 or any 
ottier network entity/application which may benefit from 
tiiat information. The implementation of MIBs such as 
tiie MIB 90 is well known and is not desaibed here in 
any detail. 

[0078] The RPM system functionality described 
above is implemented in the network manager 1 by pro- 
gramming a general purpose computer (not shown). It is 
understood that tiie preparation of the programs neces- 
sary to acconnplish this RPM functionality is obvious to 
persons of ordinary skilled in the network management 
art. particularly in view of the detailed description of the 
functionality of the management server 22 provided 
above in reference to Figures 4 through 9. 
[0079] While the invention has been described 
above witii reference to a particular type of network, fur- 
ttier modifications and improvements to support other 
types of networks which will occur to those skilled in tiie 
art, may be made within the pun/iew of tiie appended 
daims. without departing from the scope of ttie inven- 
tion in its broader aspect. 

[0080] In particular, the invention has been 
described above with respect to an IP network It is 
understood that tiie invention could also be applied to 
other types of networks. Further, the invention is not 
restiicted to SNMP networks with an INM management 
platiorm and coukJ also be used with manager-agent 
environments different from SNMP and in association 
with otiier management platforms. 
[0081 ] The RPM system has been described above 
witii reference to a particular GUI design. It is to be 
understood that other GUI designs may also be used to 
enable a GUI user to specify and monitor routes, patiis 
and associated interfaces in a network in accordance 
with the present invention. As an example, the GUI has 
been described above as having a main computer win- 
dow which is subdivided into 5 sections for entering ttie 
RPM monitoring parameters and viewing the cone- 
sponding RPM results. H is to be understood that tiie 
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computer window could be subdivided into more or less 
than 5 sections according to the GUI user's specific 
management needs. 

[0082] ft is also to be understood that other types of 
user interfaces may be used. For example, a command 
line interface (CLI) could be used. Moreover, the user 
interface has been described as being separate from 
the management server. It is to be understood that if 
necessary, the user interface may also be implen^ed 
internally to the management server and still fall wrtNn 
the purview of the present Invention. 

Claims 

1. A route and path management system for a com- 
munication netwak comprising plurality of network 
elements whereby the network elements form mul- 
tiple sets of paths, each set of paths being associ- 
ated with a respective route in the communication 
network, the route and path management compris- 
ing: 

a data collector for collecting data from the plu- 
rality of network elements whereby the data 
collected relates to at least one route and an 
associated set of paths formed in the communi- 
cation network; and 

a management server connected to the data 
collector to receive the data collected for moni- 
toring the at least one route and the associated 
set of paths formed in the communication net- 
work. 

2. The route and patii management system of daim 1 
further comprising a user interface connected to the 
management server for specifying the at least one 
route to monitor and reporting the routing perform- 
ance and path changes associated therewith. 

3. The route and path management system of claim 1 
or 2, wherein for monitoring the at least one route 
and tiie associated set of paths defined in the com- 
munication networK tiie management server is 
conprised of: 

a path trace and monitor logic unit operable to 
receive the at least one route for performing 
historical and real-time monitoring of the path 
changes of tiie associated set of patiis; and 
a performance monitor logic unit operable to 
receive the at least one route for monitoring the 
performance of the at least one route and the 
associated set of paths historically and in real- 
time. 

4. The route and path management system of claim 3 
wherein for performing historical and real-time 
monitoring of path changes of the associated set of 



paths, the path trace and monitor logic unit is com- 
prised of: 

a trace handler for receiving the at least one 
5 route to monitor; 

a path objects assemble' for assembling the 
set of paths associated wrtii the at least one 
route to monitor; and 

a patii change monitor logic unit for monitoring 
10 changes in the set of paths associated with tiie 

at least one route to monitor. 

5. The route and path management system of daim 3 
or 4 wherein for historically monitoring of the per- 

15 formance of the at least one route and the assod- 
ated set of patiis. the performance monitor logic 
unit is comprised of: 

a monitoring queue operable to receive the at 
20 least one route and hold identification and per- 

fomnance data related to tiie at least one route 
and the associated set of patiis; 
an object performance monitor logic unit con- 
nected to the oTonitoring queue for polling tiie 
25 network elements forming the associated set of 

paths for new identification and performance 
data; 

a path performance monitor logic unit con- 
nected to both the monitoring queue and the 

30 object performance monitor logic unit for com- 

puting ttie perforniance associated with each 
path of the set of paths; 
a route performance monitor logic unit con- 
nected to both the monitoring queue and the 

35 path performance monitor logic unit for com- 

puting the overall perfornnance of tiie at least 
one route; and 

a tiireshokj crossing logic unit connected to the 
object performance monitor logic unit, the path 
40 performance monitor logic unit and tiie route 

performance monitor logic unit for measuring 
the performance of the at least one route and 
the assodated set of paths against suitable 
performance tiiresholds. 

45 

6. The route and patii management system of daim 5 
wherein for monitoring the performance of tiie at 
least one route and the associated set of paths in 
real-time, the performance rTX>nitor logic unit is fur- 
so ttier comprised of: 

an object performance logic unit connected to 
the monitoring queue for polling tiie network 
elements forming tiie associated set of paths 
55 for new identification and performance data; 

a path performance logic unit connected to 
both tiie monitoring queue and the object per- 
formance logic unit for computing the perform- 
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ance associated with each path of the set of 
paths; 

a route performance logic unit connected to 
both the monitoring queue and the path per- 
formance logic unit for computing the overall s 
performance of the at least one route. 

7. The route and path management system of any of 
claims 3 to 6 wherein the management server fur- 
ther comprises a historical path and performance io 
broker for historically analysing the routing perfornh 
ance and the path changes of the at least one route 
and the associated set of paths. 

8. The route and path management system of claim 7 75 
wherein for historically analysing the routing per- 
formance and the path changes of the at least one 
route and the associated set of paths, the historical 
path and performance broker is comprised of: 

20 

a trace handler for receiving the at least one 
route; 

a path gatherer for retrieving the set of paths 
associated with the at least one route; 
an event and performance gatherer for gather- 25 
ing the routing performance data and the path 
changes of the at least one route and the asso- 
ciated set of paths; and 

a solution provider for processing the routing 
performance data and the path changes of the 3o 
at least one route and the associated set of 
paths in a form appropriate for analysis. 

9. The route and path managemem system of any of 
claims 1 to 8 wherein the data collector is operable 35 
with simple network management protocol (SNMP). 

10. The route and path management system of any one 
of claims 2 to 9 wherein the data collector is com- 
prised of a trap gatherer for gathering traps gener- 40 
ated by network elements of the comnrwnication 
network. 

11. The route and path management system of daim 

10 wherein the management server further has a 45 
trap handler connected to the trap gatherer for han- 
dling the traps generated and notifying the user 
interlace of significant events. 

12. The route and path management system of any so 
preceding daim wherein the route and path man- 
agement system is operable with integrated net- 
work management (INM). 

13. The route and path management system of any of ss 
daims 1 to 12 in combination with a database for 
storing the routing perfonmance results of the at 
least one route and the path changes associated 



therewith. 

14. The route and path management system of daim 
13 in combination with a management information 
base for provicfing SNMP access to the at least one 
mute and the assodated set of paths nnonitored. 

15. A route and path management system for a com- 
nriinication network conprising plurality of network 
elements whereby the network eiemerrts form mul- 
tiple sets of paths, each set of paths being associ- 
ated with a respective route in the conrvnunication 
network, the route and path management compris- 
ing: 

collecting means for collecting data from the 
plurality of network elements whereby the data 
collected relates to at least one route and an 
assodated set of paths formed in the comnouni- 
cation network; 

managing means connected to the collecting 
means to receive the data collected and opera- 
ble to monitor the at least one route and the 
assodated set of paths formed in the communi- 
cation network for determining routing perform- 
ance and path changes of the associated set of 
paths. 

16. The route and path management system of daim 
15 wherein the managing means comprises: 

means for performing historical and real-time 
monitoring of the path changes of the assod- 
ated set of paths; and 

means for monitoring the performance of the at 
least one route and the associated set of paths 
historically and in real-time. 

17. The route and path management system of daim 
15 or 16 further cooprising a user interface for 
reporting routing performance and path changes of 
the associated set of paths. 

ia The route and path management system of claim 
15, 16 or 17, wherein the collecting means com- 
prises a data collector. 

19. The route and path management system of claim 
15, 16 1 7 or 18, wherein the managing means com- 
prises a management server. 

20. A method for managing routes and paths in a com- 
munication network comprising a plurality of netr 
work elements whereby the network elements form 
multiple sets of paths, each set of paths conprising 
at least one fonArard path and one backward path 
and being associated with a respective route 
defined by a source endpdnt and a destination 
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endpoint in the communication network, the 
method comprising the steps of: 

collecting data from the plurality of network ele- 
ments whereby the data collected relates to at s 
least one route and an associated set of paths: 
and 

nwnitoring the at least one route and the asso- 
ciated set of paths. 

10 

21. The method of claim 20 wherein the step of vnon\- 
toring the at least one route and the associated set 
of paths comprises the steps of: 

performing historical and real-time nrwnitaing is 
of the path changes of the associated set of 
paths; and 

monitoring of the performance of the at least 
one route and the associated set of paths his- 
torically and in real-time. 20 

22. The method of claim 21 wherein the step of per- 
forming historical and real-time monitoring of the 
path changes of the associated set of paths conv 
prises the steps of: 25 

assembling each one of the set of paths; and 
monitoring the path changes of the associated 
set of paths historically and in real-time. 

30 

23. The method of daim 22 wherein the step of assem- 
bling each one of the set of paths comprises the 
steps of: 

at each of the source endpoint and sut>sequent 35 
intermediate points located between the 
source endpoint and the destination endpoint. 
collecting routing information for assembling 
the at least one forward path of the set of paths; 
and 40 
at each of the destination endpoint and subse- 
quent intenmediate points located between the 
destination endpoint and the source endpoint, 
collecting routing information for assenri)ling 
the at least one backward path of the set of 45 
paths. 
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